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ABSTRACT 

Mandated  requirements  to  share  information  across  differ¬ 
ent  sensitivity  domains  necessitate  the  design  of  distributed 
architectures  to  enforce  information  flow  policies  while  pro¬ 
viding  protection  from  malicious  code  and  attacks  devised 
by  highly  motivated  adversaries.  The  MYSEA  architecture 
uses  component  security  services  and  mechanisms  to  extend 
and  inter-operate  with  commodity  PCs,  commodity  client 
software,  applications,  trusted  components,  and  legacy  sin¬ 
gle  level  networks,  providing  new  capabilities  for  composing 
secure,  distributed  multilevel  secure  solutions.  This  results 
in  an  architecture  that  meets  two  compelling  requirements: 
first,  that  users  have  a  familiar  work  environment,  and,  sec¬ 
ond,  that  critical  mandatory  security  policies  are  enforced. 
Categories  and  Subject  Descriptors:  D.4.6  Software: 
Operating  Systems  -  Security  and  Protection,  Organization 
and  Design 

General  Terms:  Design;  Security 

Keywords:  access  controls,  authentication,  information  flow 
controls,  cryptographic  controls 

1.  INTRODUCTION 

Governments  and  organizations  call  for  the  enforcement 
of  mandatory  confidentiality  and  integrity  policies,  yet  these 
same  policies  now  mandate  the  selective  sharing  of  informa¬ 
tion  among  individuals  and  groups  with  differing  sensitivity 
attributes  [32,  1].  Applicable  environments  include:  mil¬ 
itary  coalitions,  agencies  and  organizations  responding  to 
security  emergencies,  and  mandated  sharing  in  business  and 
financial  relationships.  Neither  military  computer  systems 
and  networks,  nor  their  commercial  sector  equivalents,  are 
currently  organized  to  provide  high  assurance  support  for 
multilevel  security  policy  enforcement  and  adequate  defense 
against  increasingly  sophisticated  attacks.  The  lack  of  ro¬ 
bust  security  risks  corruption  of  critical  data  and  systems, 
leakage  of  sensitive  information,  and  degradation  of  service 
to  fundamental  infrastructure  systems.  Industrial  systems 
run  the  risk  of  economic  espionage,  while  the  lack  of  policy 
support  for  intelligence  and  Joint  Command  and  Control 
Systems  constrains  government  and  military  operations. 
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To  secure  mission-critical  information  systems,  new  trusted 
computing  approaches  are  required,  involving  both  interop¬ 
erable  system  security  features  and  standardized  security 
mechanisms.  We  describe  an  innovative  high  assurance  ar¬ 
chitecture  to  provide  trusted  security  services  and  integrated 
operating  system  mechanisms  that  can  protect  distributed 
multilevel  secure  computing  environments  from  malicious 
code  and  other  attacks.  These  security  services  and  mech¬ 
anisms  extend  and  inter-operate  with  existing  applications 
and  commodity  clients,  providing  new  capabilities  for  com¬ 
posing  secure  distributed  systems  using  commercial  off-the- 
shelf  (COTS)  components.  The  latter  objective  results  from 
the  realization  that  unless  a  secure  system  offers  users  the 
same  comfortable  and  familiar  interfaces  used  for  handling 
routine  information,  it  will  fail  due  to  lack  of  acceptability. 

The  Monterey  Security  Architecture  (MYSEA)  [37,  34, 
39,  38,  36,  55,  54]  provides  a  trusted  distributed  operat¬ 
ing  environment  for  enforcing  multilevel  security  policies. 
Careful  design  allows  it  to  encompass  many  low  assurance 
commercial  components  and  commodity  productivity  appli¬ 
cations,  with  relatively  few  specialized  high-assurance  ele¬ 
ments.  This  arrangement  protects  an  organization’s  ongoing 
investment  in  commodity  desktop  systems  and  applications, 
and  permits  these  components  to  be  integrated  into  an  en¬ 
vironment  where  enforcement  of  critical  security  policies  is 
assigned  to  more  trusted  elements.  Trust  is  derived  from 
the  application  of  high  assurance  system  design  and  devel¬ 
opment  methods  to  the  trusted  elements  as  well  as  to  the 
overall  architecture. 

The  locus  of  policy  enforcement  in  MYSEA  is  a  federa¬ 
tion  of  high  assurance  servers.  We  have  vertically  integrated 
application  security  requirements  with  underlying  security 
services,  and  can  apply  an  existing  Quality  of  Security  Ser¬ 
vice  model  and  framework  [47]  to  the  integrated  security 
structure.  Additionally,  MYSEA  supports  secure  trusted 
path  communications  between  the  user  and  the  trusted  OS, 
as  well  as  high  assurance  labeling  for  incoming  traffic  from 
legacy  single  level  networks. 

The  state  of  the  art  for  protecting  multilevel  information 
and  for  the  management  of  security  policies  and  security  ser¬ 
vices  in  support  of  critical  applications  is  advanced  through 
several  innovations: 

1.  A  distributed  security  architecture  incorporating  trusted 
components  in  support  of  multilevel  information  pro¬ 
cessing  using  commercial  and  open  source  applications. 
This  innovative  use  of  trusted  components  in  a  client- 
server  architecture  significantly  leverages  the  impact 
of  highly  trusted  systems. 
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2.  A  remote  trusted  path  mechanism  that  assures  unam¬ 
biguous  user  communication  with  the  trusted  comput¬ 
ing  base  and  is  independent  of  client  workstation  se¬ 
curity. 

3.  Techniques  for  vertical  integration  of  security  policy 
control  functions  with  underlying  security  services  in 
a  Quality  of  Security  Service  framework. 

4.  Secure  integration  of  existing  classified  networks.  These 
connections  may  be  initiated  either  from  clients  within 
the  multilevel  network  to  access  single  level  resources, 
or  from  existing  single  level  networks  to  access  re¬ 
sources  on  the  multilevel  server. 

The  remainder  of  this  paper  begins  with  a  description  of 
the  concepts  and  requirements  that  provide  the  basis  for  the 
MYSEA  architecture.  This  is  followed  by  details  regarding 
the  structural  aspects  of  primary  MYSEA  components.  In 
Section  4,  we  discuss  related  work.  We  close  with  our  con¬ 
clusions  and  a  brief  description  of  some  of  the  future  plans 
for  MYSEA. 

2.  CONCEPTS  AND  REQUIREMENTS 

MYSEA  is  a  distributed  client-server  architecture  featur¬ 
ing  a  combination  of  (relatively  few)  specialized  policy  en¬ 
forcing  components  and  multiple  open  source  and  commer¬ 
cial  off-the-shelf  components. 

The  MYSEA  network  architecture  affords  users  the  abil¬ 
ity  to  securely  access  information  across  networks  at  dif¬ 
ferent  classifications  using  standardized  commodity  appli¬ 
cations.  Highly  trustworthy  MLS  servers  provide  the  locus 
of  security  policy  enforcement,  while  the  highly  trustworthy 
Trusted  Path  Extensions  (TPEs)  and  Trusted  Communi¬ 
cations  Modules  (TCMs)  authenticate/disambiguate  users 
and  single  level  networks,  respectively.  The  TPE  is  a  gate¬ 
keeper  for  user  interaction  with  the  MYSEA  Server;  whereas 
the  TCM  controls  the  access  of  single-level  networks  to  the 
Server.  Other  system  components  provide  users  the  abil¬ 
ity  to  run  unmodified  office  productivity  tools,  web-based 
services,  and  DoD  applications.  Federated  servers  support 
scalability,  which,  when  combined  with  single  sign-on  and 
virtualization,  result  in  a  extensible  computing  environment. 

The  major  components  of  the  architecture  are  shown  in 
Figure  1  [55]  and  include; 

•  High  assurance  MYSEA  Servers,  which  provide  the  lo¬ 
cus  for  multilevel  security  policy  enforcement  and  host 
various  open  source  or  commercial  application  proto¬ 
col  servers. 

•  Client  workstations  executing  popular  software  appli¬ 
cations;  and  TPEs,  which  interface  between  the  client 
and  the  MYSEA  Server,  providing  trustworthy  net¬ 
work  security,  identihcation  and  authentication,  and 
policy  support. 

•  Existing  classihed  single  level  networks  connected  to 
the  MYSEA  Server  via  TCMs  and  link  encryptors. 
TCMs  complement  link  encryption  by  ensuring  proper 
labeling  of  data  passed  back  to  the  MYSEA  Server. 

•  Single  level  servers  in  the  Multilevel  Enclave  area  pro¬ 
vide  application  services  to  both  local  clients  and  those 
in  the  legacy  networks. 


The  MYSEA  Server  enforces  a  unihed  mandatory  access 
control  policy  for  both  conhdentiality  (including  read-down) 
and  integrity.  With  this  basis,  MYSEA  provides  services  to 
support  high  assurance  remote  client  authentication,  session 
management,  and  connection  to  legacy  single  level  networks. 
Users  also  have  access  to  a  set  of  application  services,  includ¬ 
ing  SMTP,  IMAP,  and  HTTP,  which  run  on  the  MYSEA 
Server.  Support  for  regrading  policies  is  implemented  in 
trusted  applications  that  are  constrained  by  the  underlying 
reference  validation  mechanism.  Multiple  intercommunicat¬ 
ing  MYSEA  Servers  provide  scalability  within  the  security 
policy  perimeter. 

2.1  Usage  Scenario 

End  users  operate  at  client  computers  on  the  local  multi¬ 
level  LAN  as  well  as  on  the  legacy  single  level  networks  (see 
Coalition,  SIPRNet,  and  NIPRNet  Enclaves  in  Figure  1). 

On  the  MLS  LAN,  the  Trusted  Path  Extension  provides 
a  trusted  path  by  which  users  log  on  to  the  MYSEA  system. 
The  TPE  is  a  special  purpose  high  assurance  component 
inserted  between  the  untrusted  client  workstation  and  the 
MLS  LAN.  TPE  log-on  establishes  an  identity  for  audit  and 
access  control  purposes;  then  the  user  negotiates  a  session 
level  from  the  range  of  security  levels  bounded  by  his  clear¬ 
ance.  The  session  level  determines  the  domain  of  data  and 
resources  accessible  to  the  user  during  that  session,  per  the 
MLS  policy. 

Subsequent  to  session  level  negotiation,  the  user  can  then 
log  on  to  the  client  workstation  and  use  its  software  (e.g., 
web  browser,  e-mail  client  applications,  or  various  office  pro¬ 
ductivity  tools)  locally  or  to  access  several  types  of  remote 
services:  MLS  services  on  the  MYSEA  Server,  single-level 
services  hosted  on  servers  in  the  local  multilevel  enclave, 
and  single-level  services  hosted  on  servers  in  the  remote  sin¬ 
gle  level  networks.  To  meet  object  reuse  requirements  [53], 
client  state  is  purged  at  the  end  of  each  session,  and  data 
created  or  modihed  on  the  clients  is  stored  on  the  MYSEA 
Server. 

At  any  time,  the  user  can  invoke  the  trusted  path  to  re¬ 
quest  a  session  level  change,  log  off,  etc.  The  Trusted  Path 
Extension  blocks  access  to  the  network  while  the  user’s  se¬ 
curity  attributes  are  in  flux  during  such  operations. 

Legacy  network  users  are  authenticated  in  their  remote 
environment,  the  senstivity  of  which  establishes  their  session 
levels  for  actions  in  the  MYSEA  environment.  These  remote 
users  are  provided  two  types  of  services:  MLS  services  on  the 
MYSEA  Server,  and  single-level  services  hosted  on  servers 
in  the  multilevel  enclave. 

2.2  Threats  and  Requirements 

The  threats  that  MYSEA  is  designed  to  address  fall  into 
two  major  classes  [34]:  developmental  threats  and  oper¬ 
ational  threats.  The  former  includes  insiders  who  intend 
to  subvert  the  system,  while  the  latter  fall  into  three  sub¬ 
classes:  network  threats,  malicious  software,  and  user  or 
application  misbehavior. 

Developmental  threats  include  errors  made  by  the  devel¬ 
opment  team  or  the  malicious  insertion  of  unintended  func¬ 
tionality  by  adversaries,  both  of  which  undermine  or  subvert 
the  ability  of  the  system  to  protect  itself  from  tampering  or 
to  continuously  enforce  critical  security  policy  [2,  52]. 

Network  threats  are  attacks  to  the  communications  proto¬ 
cols  within  the  MLS  LAN  or  the  MLS  Enclave.  For  exam- 
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Figure  1:  Monterey  Security  Architecture 


pie,  an  attempt  could  be  made  to  use  a  non-TCBE  equipped 
workstation  attached  to  the  LAN  to  modify  or  collect  com¬ 
munications  traffic. 

Malicious  software  is  the  principal  operational  threat  to 
the  server.  This  software  may  attempt  to  violate  security 
policies  for  information  confidentiality  or  integrity  by  ob¬ 
taining  unauthorized  access  to  information.  Trojan  Horse 
software  represents  a  classic  example  of  malicious  software 
and  can  be  used  to  either  directly  or  indirectly  access  infor¬ 
mation  [43]. 

Misbehavior  applies  to  user  actions  at  the  client  worksta¬ 
tion  that  may  initiate  or  participate  in  attacks.  In  this  case, 
either  users  or  their  software  attempt  to  bypass  the  TCB 
Extension  in  order  to  gain  unauthorized  access  to  protected 
information. 

The  system  requirements  are  constructed  to  address  these 
threats  (see  Appendix  A  in  [34]).  Next,  we  present  system 
requirements  in  three  categories:  access  control  policies,  as¬ 
surance,  and  security  features. 

2.3  Access  Control  Policies 

MYSEA  supports  both  mandatory  access  control  (MAC), 
and  discretionary  access  control  (DAC): 

1.  MAC  -  under  this  policy,  the  MYSEA  Server  enforces 
lattice-based  policies,  such  as  the  national  rules  regard¬ 
ing  access  to  classified  information  represented  by  the 
TOP  SECRET,  SECRET,  and  UNCLASSIFIED  sen¬ 
sitivity  labels.  This  requirement  is  met  by  the  separa¬ 
tion  of  resources  into  equivalence  classes,  and  explicitly 
allowed  flows  between  classes. 

2.  DAC  -  under  this  policy,  MYSEA  Server  restricts  the 
ability  of  processes,  acting  on  behalf  of  users,  to  access 
data  objects  such  as  files.  The  access  decisions  are 
based  on  the  MYSEA  user  identities  associated  with 
the  processes,  and  permissions  that  are  registered  with 
the  Server.  Applications  and  users  may  modify  permis¬ 
sions  via  runtime  functions. 


2.4  Assurance 

Our  rigorous  security  engineering  and  development  pro¬ 
cesses  [34]  are  intended  to  provide  robust  assurance  of  pol¬ 
icy  enforcement  by  the  trusted  components  in  the  MYSEA 
system.  Under  this  process,  the  threat  model  and  system  re¬ 
quirements  specifications  form  the  basis  for  the  system  archi¬ 
tecture.  From  these,  we  derive  functional  specifications  and 
corresponding  detailed  design  specifications,  source  code, 
verification  and  testing.  A  key  element  of  system  assurance 
is  the  allocation  of  policy  to  components  that  occurs  during 
the  design  process. 

2.4.1  High  Assurance  Allocation  of  Policy 

In  the  design  of  a  distributed  system  architecture  intended 
to  meet  high  assurance  requirements,  the  definition  of  both 
the  TCB  perimeter  and  the  allocation  of  security  policy  to 
various  components  permits  the  system  to  be  decomposed 
into  analyzable  components.  A  number  of  basic  principles 
and  security  engineering  notions  come  into  play.  Among 
these  are  the  ordering  of  security  dependencies,  the  order¬ 
ing  of  trust  and  trustworthiness  [45],  and  the  principle  of 
least  privilege  [65]  as  manifested  in  the  organization  of  com¬ 
ponents  that  enforce  or  support  the  enforcement  of  policy,  as 
well  as  components  that  are  trusted  with  respect  to  policy. 

Security  dependencies  in  the  system  should  be  partially 
ordered,  since  if  the  dependencies  are  circular  then  an  in¬ 
creasingly  large  component  must  be  examined  in  its  totality 
to  determine  if  it  maintains  the  desirable  security  properties. 
Furthermore,  for  their  correct  operation,  partially  ordered 
components  will  trust  the  components  upon  which  they  de¬ 
pend.  If  the  components  that  are  being  depended  upon  are 
not  trustworthy,  i.e.,  demonstrates  some  measurable  level 
of  compliance  with  its  stated  functionality,  then  no  amount 
of  trustworthiness  in  the  dependent  component  can  remedy 
the  architectural  flaw  created  by  an  incorrect  dependency. 

If  an  overall  security  policy  can  be  decomposed  into  dis¬ 
crete  goals  (e.g.,  rule  sets);  and  the  system  design  is  such 
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that  the  enforcement  of  each  individual  goal  can  be  allo¬ 
cated  to  one  or  more  operational  components,  the  resulting 
security  architecture  will  manifest  a  composition  of  policy 
subsets  (e.g.,  “TCB  subsets”  in  [70]).  This  organization  sup¬ 
ports  a  realization  of  the  principle  of  least  privilege,  whereby 
no  subset  implementation  is  endowed  with  more  authority 
(or  commensurate  trust)  than  is  necessary  to  perform  its 
allocated  function(s). 

The  design  of  architectures  that  reflect  the  notions  de¬ 
scribed  above  is  currently  a  non-formulaic  process,  and  re¬ 
quires  careful  consideration  over  and  above  following  estab¬ 
lished  security  engineering  principles.  One  must  understand 
how  component  composition  may  affect  the  ability  of  the 
system  to  properly  enforce  each  of  its  constituent  policies. 
For  example,  improper  organization  may  permit  components 
enforcing  “weaker  policies”,  like  DAC,  to  deny  those  enforc¬ 
ing  stronger  policies,  like  MAC,  from  meeting  their  specified 
requirements. 

2.5  Security  Features 

Major  security  features  that  MYSEA  is  designed  to  sup¬ 
port  include: 

1.  Secure  connections  to  classified  networks 

2.  Centralized  security  management 

3.  Use  of  adaptive  security  techniques  to  provide  dynamic 
security  services 

4.  True  multilevel  access  to  data  at  multiple  levels  of  se¬ 
curity  using  a  single  commodity  workstation 

5.  Integration  of  multilevel  security  with  existing  sensi¬ 
tive  networks 

6.  High  assurance  trusted  communication  channels  to  clas¬ 
sified  networks 

7.  Secure  single  sign-on  across  multiple  MLS  servers 

8.  Server  replication  to  support  scalability 

9.  IPv6  in  a  multilevel  context 

10.  Interoperability  with  the  DoD  PKI  infrastructure 

11.  High  assurance  trusted  path  techniques  for  managing 
access  to  classified  networks 

In  addition  to  the  obvious  features  listed  above,  two  other 
features  are  descibed  in  more  detail  below. 

2. 5. 1  Policy -Aw are  Applications 

Policy-aware  means  that  an  application  has  been  modi¬ 
fied  to  run  in  a  given  policy  environment  without  needing 
extraordinary  privileges,  and  is  then  both  fully  functional 
and  constrained  by  that  policy  [33].  Usually,  applications 
do  not  need  to  be  policy  aware,  and  are  suitably  constrained 
by  the  underlying  policy  mechanisms.  However,  in  some  en¬ 
vironments,  such  as  those  with  MLS  policies,  application 
modifications  are  required. 

MYSEA’s  HTTP  server,  which  includes  an  MLS-enabled 
wiki,  is  a  concrete  example  of  a  policy-aware  application.  In 
the  wiki,  multilevel  technology  permits  collaborators  with 
different  security  attributes  in  a  coalition  environment  to 


maximize  information  sharing  while  still  adhering  to  the  con¬ 
straints  of  the  overall  security  policy  [58].  Multilevel-aware 
instances  of  the  wiki  execute  as  untrusted  subjects  within 
the  context  of  a  multilevel  architecture.  MLS  policy  is  en¬ 
forced  with  high  assurance  by  the  MYSEA  Server,  which 
ensures  that  wiki  users  logged  in  at  high  sensitivity  levels 
are  able  to  read  and  post  information  at  their  level,  but 
may  not  write  information  to  lower  sensitivity  levels.  Corre¬ 
spondingly,  users  at  lower  sensitivity  levels  are  only  allowed 
access  to  less  sensitive  information. 

2.5.2  Dynamic  Security  Services 

Complex  and  adaptive  networks  may  require  changes  on 
demand  to  the  security  provided.  When  conditions  on  the 
network  change,  requirements  for  security  —  e.g.,  restric¬ 
tions  as  seen  from  the  users’  or  attackers’  point  of  view  — 
may  also  change.  In  MYSEA,  the  DSS  Quality  of  Secu¬ 
rity  Service  (QoSS)  mechanisms  located  on  the  TPE  and 
at  the  MYSEA  Server  can  modify  the  protection  services 
afforded  to  an  ongoing  session,  in  response  to  a  change  noti¬ 
fication.  The  selection  of  protection  mechanisms  for  client- 
server  communications  may  be  based  upon  network  condi¬ 
tions  such  as  INFOCON  mode.  A  version  of  IPSec,  adapted 
to  provide  automated,  dynamic  QoSS  through  the  use  of 
an  enhanced  version  of  a  policy  server  such  as  Keynote  [13] 
permits  selection  of  protection  mechanisms. 

3.  MYSEA  DISTRIBUTED  STRUCTURE 

The  MYSEA  Server  implements  both  multilevel  and  dis¬ 
cretionary  security  policies  while  maintaining  support  for 
new  and  legacy  applications  and  unmodified  commodity  client 
systems.  The  architecture  supports  protocols  and  equip¬ 
ment  from  a  wide  range  of  vendors  as  well  as  secure  in¬ 
teraction  with  external  classified  networks.  The  mandatory 
access  control  (MAC)  security  policy  is  based  on  the  Bell 
and  LaPadula  [10]  confidentiality  policy  and  the  Biba  [12] 
integrity  policy. 

The  access-control  policy  foundation  for  the  MYSEA  Server 
is  the  BAE  XTS-400  [5],  which  has  been  awarded  a  Com¬ 
mon  Criteria  [18]  EAL5  certification  (see  http://www.niap- 
ccevs.org/cc-scheme/st/vidl0293)  for  its  combined  hardware 
base  and  STOP  operating  system.  MYSEA  extends  the 
XTS-400  with  an  MLS  network  interface  and  TCP/IP  stack, 
remote  trusted  path,  remote  file  system,  and  remote  inter¬ 
active  shell  capability. 

The  MYSEA  software  architecture  is  illustrated  in  Fig¬ 
ure  2.  The  MYSEA  Server,  TPE  and  TCM  components  all 
have  a  common  foundation:  a  high  assurance  operating  en¬ 
vironment  (i.e.,  LPSK  [46]  and  STOP  OS),  the  Protected 
Communications  Service  (PCS)  and  DSS. 

The  PCS  component  provides  IPsec-based  protected  com¬ 
munication  channels  between  the  TPE  and  server,  and  be¬ 
tween  the  TCM  and  the  server.  The  DSS  components  im¬ 
plement  a  dynamic  service  management  mechanism  that  can 
adjust  PCS  protection  in  response  to  external  changes  and 
threats,  as  envisioned  for  the  Global  Information  Grid  (GIG) 
[79]. 

The  Trusted  Path  Service  (TPS)  and  Trusted  Path  Appli¬ 
cation  (TPA)  components  together  enforce  the  identification 
and  authentication  supporting  policy  to  ensure  that  only  au¬ 
thorized  users  can  gain  access  to  the  system.  The  TPA  af¬ 
fords  the  users  unspoofable  access  to  security  critical  services 
and  is  invoked  via  a  Secure  Attention  Key.  The  TPS  com- 


42 


MYSEA  Server 


Process  Creation 


User 


Sys 

High 


I’s  (^YeT^ 

~  ef) 

£L  E  N 
V)  ^  \  No  ' 


Sys 

High 


MLS  Level 
>  users  > 


Sys 

Low 


APS 

ix' 

CGI 


Figure  3:  MYSEA  Server  Processes 


Figure  2:  MYSEA  Software  Architecture 


ponent  on  the  server  handles  user  authentication  and  ses¬ 
sion  negotiation  functions.  Likewise,  the  Trusted  Channel 
Service  (TCS)  and  the  Trusted  Channel  Application  (TCA) 
components  ensure  that  traffic  between  a  single  level  net¬ 
work  and  the  MYSEA  Server  are  properly  labeled  at  the 
classification  level  of  the  particular  network. 

3.1  Trusted  Path  Extension  and  Trusted 
Channel  Module 

The  Trusted  Path  Extension  (TPE)  and  Trusted  Commu¬ 
nications  Module  (TCM)  help  to  enforce  policies  under  the 
direction  of  the  MYSEA  Server,  but  neither  is  empowered 
to  make  policy  decisions. 

When  a  user  logs  in,  the  TPE  passes  the  user’s  identity 
credentials  to  the  MYSEA  Server,  which  validates  the  login 
attempt  and  instructs  the  TPE  whether  to  allow  or  deny 
access  to  the  network.  In  negotiating  a  session  level,  the 
TPE  passes  the  user’s  session  level  request  to  the  Server 
for  a  decision.  After  a  successful  login  and  session  level 
negotiation,  the  TPE  allows  the  user  to  access  the  MLS  LAN 
and  the  MYSEA  Server  as  well  as  services  in  the  Multilevel 
Enclave  and  the  single  level  networks. 

Similarly,  the  Trusted  Channel  Module  (TCM)  helps  to 
map  the  single  level  networks  to  specific  security  levels,  en¬ 
suring  for  example,  that  “IP-spoofing”  could  not  be  used  by 
a  malicious  remote  user  to  access  the  wrong  level  of  informa¬ 
tion.  Users  on  these  networks  can  only  access  data  on  the 
MYSEA  Server  at  the  classification  level  of  the  single  level 
network  from  which  they  are  operating. 

3.2  Workstations 

The  use  of  a  single  client  workstation  for  cross-domain  ac¬ 
cess  provides  a  dramatic  physical  footprint  reduction  com¬ 
pared  to  other  approaches.  However,  without  appropriate 
security  measures,  use  of  a  single  workstation  could  mag¬ 
nify  the  risk  of  information  leakage.  In  particular,  residual 
information  in  memory  or  other  internal  components  of  the 
workstation  allocated  during  a  high  session  may  be  improp¬ 
erly  reallocated  to  a  low  session.  To  address  these  object 
reuse  issues,  MYSEA  uses  stateless,  i.e.  diskless,  clients. 
All  user  data  objects  and  related  metadata  are  stored  on 
the  MLS  server  rather  than  on  the  workstation.  To  avoid 
object  reuse  with  respect  to  state  elements  on  the  client 
workstation,  users  recycle  workstation  power  whenever  they 


transition  to  a  less  sensitive  session.  Boot  odometer  support 
[75]  could  monitor  this  procedure. 

3.3  DSS  Tool 

The  DSS  tool  manages  the  IPsec  configurations  available 
to  the  MYSEA  components.  At  initialization,  the  DSS  Ad¬ 
min  Tool  connects  to  the  DSS  Server  and  thereafter,  it  con¬ 
veys  users’  input  to  the  DSS  Server.  Its  functions  include: 
Set  Policy;  Reload  Policies;  get  and  display  Server  IKE  Secu¬ 
rity  Association  Database  information;  and  get  and  display 
Server  IPSec  Security  Policy  Database  information. 

3.4  MYSEA  Server 

The  MYSEA  Server  comprises  a  set  of  interacting  pro¬ 
cesses  that  implement  various  multilevel  services  and  single- 
level  applications.  As  shown  in  Figure  3,  trusted,  multilevel 
processes  control  the  invocation  of  single-level  applications 
that  interact  with  the  user  at  the  user’s  current  session  level. 

3.4.1  Multilevel  Services 

MYSEA  offers  the  following  multilevel  services:  Trusted 
Path,  Secure  Session,  Trusted  Remote  Session,  and  Dynamic 
Security.  Single-level  application  support  is  provided  by  Ap¬ 
plication  Protocol  Servers  and  Remote  Applications,  along 
with  support  from  CGI  processes. 

Trusted  Path  Service 

The  Trusted  Path  Service  is  provided  by  a  single  TPS 
parent  and  multiple  TPS  child  processes.  The  parent  pro¬ 
cess  is  started  at  initialization  and  monitors  the  network  for 
TPE  connection  requests.  If  a  request  comes  from  a  valid 
TPE,  the  TPS  parent  creates  a  TPS  child  process  to  service 
the  connection  (e.g.,  handle  TPE  requests  to  login,  change 
session  level,  run,  and  logout).  The  TPS  parent  and  child 
processes  execute  at  the  system  network  security  level  (viz., 
system  high)  and  have  privileges  to  access  system  identifi¬ 
cation  and  authentication  information,  and  both  MAC  and 
DAC  bypass  privileges. 

The  TPS  child  processes  also  create  the  Trusted  Remote 
Session  Server  (TRSS)  parent  process  for  each  user  name 
and  session  level  pair  (see  below);  and  support  the  DSS 
server  and  DSS  Clients  with  respect  to  various  user/TPE 
activities.  The  TPS  child  alerts  the  DSS  Server  when  it  en¬ 
counters  an  error  and  when  the  user  has  initiated  a  RUN 
or  Logout  command.  Depending  on  the  situation,  the  DSS 
server  may  take  various  actions,  such  as  changing  the  secu¬ 
rity  configuration  of  the  DSS  Client,  or  blocking  the  TPE. 


43 


Secure  Session  Service 

At  start-up,  the  Secure  Session  Daemon  (SSD)  process 
starts  a  Secure  Session  Server  (SSS)  parent  process  for  each 
supported  application  protocol.  Each  SSS  parent  accepts 
and  validates  application  protocol  service  requests  from  TPE 
clients  for  its  particular  TCP/IP  protocol  (IMAP,  SMTP, 
HTTP,  etc).  The  parent  process  ensures  that  the  request  is 
from  either  a  TPE  with  a  valid  session,  or  a  valid  Remote 
Application,  and  it  creates  an  SSS  child  process  to  service 
the  connection.  After  creating  the  child,  the  parent  contin¬ 
ues  to  monitor  for  new  application  protocol  service  requests. 

The  SSS  child  process  creates  an  Application  Protocol  Server 
(APS)  process  and  handles  communications  between  the 
client  TPE  (or  Remote  Applications)  and  the  APS.  The  APS 
process  is  created  with  the  privileges  of  the  user  session  re¬ 
sponsible  for  the  TPE  or  RA  request.  The  SSS  child  and  the 
APS  processes  communicate  via  a  MYSEA  Socket  which  is 
allocated  by  the  TPS  child  process. 

Trusted  Remote  Session  Service 

The  Trusted  Remote  Session  Serviee  (TRSS)  processes 
handle  communication  requests  from  Remote  Applications. 
There  is  a  TRSS  parent  process  for  each  user  name  and  ses¬ 
sion  level  pair  —  e.g.,  a  given  user  might  have  sessions  at 
the  same  level  on  different  client  workstations,  all  of  which 
would  be  serviced  by  the  same  TRSS  parent.  The  TRSS 
parent  process  creates  a  TRSS  child  for  each  new  remote 
connection  request  from  a  Remote  Application  (RA).  The 
TRSS  child  process  handles  all  remote  connections  with  the 
RA. 

For  each  connection  established  for  the  RA  to  the  destina¬ 
tion,  the  TRSS  child  process  updates  a  database  to  associate 
a  user  ID  and  session  level  with  a  particular  destination  IP, 
destination  port,  source  IP  and  source  port. 

The  TRSS  processes  execute  at  the  system  network  se¬ 
curity  level,  and  they  have  privileges  to  communicate  with 
remote  applications,  and  to  be  started  by  a  trusted  process. 

Dynamic  Security  Service 

The  Dynamic  Security  Service  (DSS)  include  a  DSS  Server 
Parent  process,  one  or  more  DSS  Server  child  processes,  one 
or  more  DSS  Clients,  and  the  DSS  tool  (see  3.3  for  a  de¬ 
scription  of  the  latter).  The  DSS  Clients  and  DSS  Tool  are 
typically  on  different  nodes  of  the  network  than  the  MYSEA 
Server. 

DSS  Server  parent  handles  communication  requests  from 
DSS  Clients.  It  creates  a  TRSS  child  for  each  new  connec¬ 
tion  request,  ensuring  that  there  is  only  one  connection  for 
each  DSS  Client.  The  DSS  Server  parent  also  handles  com¬ 
mands  from  the  DSS  Admin  Tool  and  the  TPS  process  — 
e.g.,  to  change  the  dynamic  parameter  or  load  a  new  config¬ 
uration  —  to  which  it  responds  by  passing  these  commands 
to  the  appropriate  DSS  Server  child. 

The  DSS  Clients  coordinate  security  policies  with  the  PCS 
components,  manage  IKE  daemons,  and  take  direction  from 
the  DSS  child  processes.  The  DSS  child  may  request:  the 
load/unload  of  a  security  configuration,  restart  of  its  IKE 
daemon,  and  the  return  of  IKE/IPSec  information. 

3.4.2  Application  Invocations 

Applications  may  be  invoked  on  the  MYSEA  Server  from 
client  workstations,  as  well  as  from  components  on  the  server. 

The  Application  Protocol  Server  (APS)  process  implements 
the  server  side  of  an  application  level  client/server  proto¬ 
col.  MYSEA  provides  the  following  APS  services:  HTTP 


(Apache),  WebDav,  IMAP,  SMTP,  and  MLS  Wiki.  An  APS 
process  communicates  with  the  client  via  a  MYSEA  socket 
managed  by  an  SSS  child  process.  The  program  for  an  APS 
process  is  an  implementation  of  an  industry  standard  ap¬ 
plication  protocol,  which  is  policy  aware,  i.e.,  it  has  been 
modified  to  allow  it  to  interact  in  a  multilevel  environment 
and  to  use  the  MYSEA  socket  infrastructure;  e.g.,  calls  to 
socket  in  the  APS  are  changed  to  mskDsocket. 

One  particular  APS,  using  the  HTTP  protocol,  supports 
a  menu  of  Remote  Applications  from  which  the  user  at  the 
client  workstation  can  choose.  In  response  to  such  a  choice, 
the  HTTP  APS  invokes  a  simple  CGI  process,  which  initiates 
the  chosen  Remote  Application. 

Users  can  launch  certain  interactive  shell  sessions  via  the 
WebShell  CGI  program,  and  can  use  the  MYSEA  WebDAV 
APS  to  navigate  the  MYSEA  Server’s  file  structure  (e.g., 
home  directories  and  the  Apache  document  root). 

The  Remote  Application  (RA)  is  an  application  program 
executing  on  the  server  on  behalf  of  the  client.  As  with  the 
APS  processes,  the  program  for  an  RA  process  is  an  im¬ 
plementation  of  an  industry  standard  application  protocol, 
which  has  been  modified  to  allow  it  to  interact  in  a  multilevel 
environment  and  to  use  the  MYSEA  socket  infrastructure. 
An  RA  process  communicates  with  the  client  via  a  MYSEA 
Socket  managed  by  a  TRSS  child  process.  For  example, 
when  a  RA  wants  to  establish  a  new  remote  connection,  it 
signals  the  TRSS  parent  process,  which  starts  a  TRSS  child 
process  to  handle  the  connection. 

MYSEA  includes  the  Trivial  File  Transfer  Protocol  (TFTP) 
remote  application. 

4.  RELATED  WORK 

Hinke  suggested  the  idea  of  a  high  assurance  server  to 
provide  a  locus  of  multilevel  secure  control  to  single  level 
clients  [31].  In  his  design  sketch,  clients  were  relegated  to 
a  single  level  and  were  connected  to  the  multilevel  server 
via  single  level  network  links.  Although  possibly  useful  in 
certain  static  situations,  the  architecture  does  not  provide 
the  flexibility  inherent  in  the  MYSEA  design.  By  restrict¬ 
ing  the  client  to  a  single  level  throughout  its  lifetime,  users 
must  access  multiple  clients  in  order  to  manipulate  informa¬ 
tion  at  several  levels.  In  contrast,  MYSEA  allows  clients  to 
renegotiate  session  levels  and  users  need  only  one  client. 

Rushby  and  Randell  [64]  describe  a  design  for  a  distributed 
secure  system  that  utilizes  trusted  network  interface  units 
(TNIUs)  to  connect  workstations  at  different  access  classes 
to  a  local  area  network,  through  which  access  to  a  dis¬ 
tributed  multilevel  file  server  is  provided.  Identification  and 
authentication  of  users,  as  well  as  session  level  negotiation 
via  the  TNIUs  is  also  described.  Over  and  above  this  func¬ 
tionality,  the  MYSEA  architecture  also  allows  a  more  gen¬ 
eral  purpose  client-server  operating  environment,  whereby 
new  application  servers  can  be  easily  added  to  the  system, 
and  thin  clients  are  easily  supported. 

Various  virtual  machine  monitor  approaches  have  been 
suggested  ]14,  42,  7]  for  supporting  COTS  applications  while 
reliably  separating  different  domains  of  data.  In  general,  for 
these  approaches  to  be  trustworthy  requires  both  the  use  of 
strictly  virtualizable  hardware  ]29],  and  a  trustworthy  mon¬ 
itor  mechanism  for  separating  the  activities  of  the  virtual 
machines.  Creating  a  monitor  sufficiently  trusted  to  both 
separate  different  domains  of  activity,  and  allow  read-down 
to  less  sensitive  domains  (as  does  MYSEA)  is  all  the  more 
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difficult.  While  at  least  one  was  designed  to  provide  high 
assurance  read-down  capabilities  [42],  it  was  never  fielded. 
The  VMM  approach  remains  problematic  for  separation  of 
different  domains  of  data  because  of  the  difficulty  of  creat¬ 
ing  a  trnsted  VMM.  This  task  is  made  even  more  difhcnlt 
becanse  many  cnrrent  microprocessors  are  not  strictly  vir- 
tualizable  [62],  which  increases  the  complexity  of  software. 

Non-distributed  approaches  to  support  access  to  multi¬ 
level  data  via  COTS  applications  have  been  proposed  in 
Seaview  and  some  VMM  architectures  [22,  50,  60[.  Purple 
Pennelope  has  limited  assurance,  as  it  runs  as  a  user-level 
application  wrapping  Windows  NT,  and  it  does  not  snpport 
a  modifiable  session  level.  The  others  rely  on  an  underlying 
reference  validation  mechanism  that  controls  access  to  mnl- 
tilevel  data.  The  MYSEA  project  extends  certain  concepts 
from  these  projects  into  a  distributed  environment. 

Replication  architectures  [27[  provide  a  simple  technique 
to  achieve  near-term  multilevel  security  by  copying  all  in¬ 
formation  at  low  security  levels  to  all  dominating  levels.  On 
a  small  scale,  they  may  work  rather  well;  on  a  large  scale, 
in  terms  of  both  the  number  of  documents  to  be  replicated 
and  the  number  of  security  levels  to  which  documents  are 
replicated,  they  are  untenable.  The  preponderance  of  DoD 
information  is  either  unclassified  or  designated  sensitive  but 
unclassified.  Similar  proportions  hold  in  the  commercial  sec¬ 
tor.  Replication  of  vast  amounts  of  data  to  all  higher  levels 
seems  infeasible.  MYSEA  does  not  use  replication  as  a  fun¬ 
damental  mechanism,  so  avoids  these  problems. 

The  Naval  Research  Laboratory  (NRL)  Network  Pump 

[40]  allows  messages  from  a  low  sensitivity  level  to  be  sent 
to  a  high  sensitivity  level,  and  prohibits  messages  and  other 
information  from  going  in  the  reverse  direction.  Addition¬ 
ally,  the  NRL  Pump  has  been  proposed  as  part  of  an  over¬ 
all  network  architecture  to  provide  more  general  two-way 
connectivity  between  multiple  subnets  at  different  sensitiv¬ 
ity  levels,  resulting  in  a  multiple  single-level  (MSL)  network 

[41] .  The  capital  and  administrative  cost  of  separately  main¬ 
tained  LANs  is  a  drawback  that  the  MYSEA  avoids. 

Starlight  [3]  was  designed  to  support  logically  separate 
single-level  workstations  connected  by  a  switch  to  data  man¬ 
agement  subsystems  at  different  (single)  levels.  Software  as¬ 
sociated  with  the  switch  ensures  that  the  current  level  of 
the  workstation  matches  the  level  of  the  data  subsystem  in¬ 
dicated  by  the  switch  setting.  Starlight  also  allows  low  con¬ 
fidentiality  information  to  flow  through  the  switch  to  high 
sessions,  providing  a  “read-down  capability.”  This  approach 
has  the  same  basic  drawbacks  as  the  MSL  network,  described 
above. 

4.1  Other  Multilevel  Variations 

The  ruleset  based  access  control  (RSBAC)  system  [59]  is 
a  Linux  extension  wherein  all  security  relevant  system  calls 
are  routed  through  a  central  decision  component.  Access- 
control  decisions  are  based  on  the  type  of  access  and  on 
attributes  attached  to  both  the  calling  subject  and  the  target 
to  be  accessed.  MYSEA’s  DSS  mechanism  allows  both  a 
more  fine-grained  and  a  more  dynamic  security  policy. 

The  Security-Enhanced  (SE)  Linux  project  is  an  approach 
to  controlling  multiple  information  domains  in  an  open  source 
operating  system  [49,  71].  The  Security-Enhanced  Linux 
project  has  not  yet  defined  several  mechanisms  provided  by 
MYSEA: 

•  Remote-client  login  to  the  trusted  OS 


•  Trusted  path  communications  with  the  trusted  OS 

•  Changing  a  user  session  security  level 

•  A  mechanism  for  assigning  security-domain  context  to 
a  newly  received  network  connection 

•  Trusted,  rather  than  client,  support  for  fPsec  message 
labeling 

•  Support  for  untrusted  clients,  i.e.,  clients  not  based  on 
Security-Enhanced  Linux. 

Content-based  Information  Security  [66]  relies  on  various 
authentication  and  cryptographic  technologies  to  mediate 
user’s  access  to  information,  but  like  the  other  variants  dis¬ 
cussed  in  this  section  provides  no  underlying  basis  of  trust  to 
ensure  against  subversion  or  malicious  software  that  might 
corrupt  or  leak  information. 

4.2  Trusted  Path 

Trusted  path  refers  to  mechanisms  that  provide  assurance 
that  security-critical  functions  are  provided  by  the  real  sys¬ 
tem  rather  than  masquerading  software.  Commercial  sys¬ 
tems,  such  as  Windows  [51],  Trusted  Solaris  [72],  and  XTS- 
400  [76]  have  implemented  trusted  path  mechanisms,  fn  the 
case  of  Windows  and  Solaris,  it  is  notable  that  the  process¬ 
ing  of  security  requests  is  handled,  at  least  partially,  outside 
of  the  system  security  perimeter  (unless  the  entire  system  is 
included  within  that  perimeter,  thus  nullifying  any  possible 
assurance  arguments).  In  contrast  to  the  MYSEA  architec¬ 
ture  trusted  path  mechanism,  the  XTS-400  itself  does  not 
support  a  remote  trusted  path. 

4.3  Dynamic  Security  Services 

Dynamic  Security  Services  (sometimes  referred  to  as  “Qual¬ 
ity  of  Security  Service,”  [35])  refers  to  offering  variable  levels 
of  security  to  both  users  and  tasks  in  support  of  increasing 
system  quality.  Thus,  security  is  transformed  from  a  per¬ 
formance  obstacle  into  an  adaptive,  constructive  network 
management  parameter. 

Historically,  there  have  been  several  efforts  in  this  direc¬ 
tion.  A  quality  of  protection  parameter  is  provided  in  the 
GSSAPI  specification  [48].  This  parameter  is  intended  to 
manage  the  level  of  protection  provided  to  a  message  com¬ 
munication  stream  by  an  underlying  security  mechanism  (or 
service),  “allowing  callers  to  trade  off  security  processing 
overhead  dynamically  against  the  protection  requirements 
for  particular  messages.”  Another  early  reference  to  a  vari¬ 
able  security  service  is  that  of  Schneck  and  Schwan  [67], 
which  discusses  variable  packet  authentication  rates  with  re¬ 
spect  to  the  management  of  system  performance.  References 
to  security  in  the  QoS  literature  can  be  found  in  [19,  4,  77], 
although  little  is  mentioned  there  of  security  as  a  functional 
QoS  dimension. 

5.  CONCLUSIONS  AND  FUTURE  WORK 

The  need  for  high-assurance  architectures  that  implement 
multi-domain  information  protection  mechanisms  is  widespread 
and  growing.  However,  such  architectures  will  not  be  adopted 
unless  they  provide  users  with  currently  required  function¬ 
ality,  the  ability  to  easily  incorporate  new  applications  and 
software  updates,  and  a  familiar  interface. 

MYSEA  is  a  trusted  distributed  operating  environment 
for  enforcing  multi-domain  security  policies  that  supports 
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unmodified  COTS  productivity  applications  in  support  of 
usability.  The  architecture  encompasses  a  combination  of 
many  (untrusted)  commercial  components  and  relatively  few 
trusted  multi-domain  components.  MYSEA  introduces  sev¬ 
eral  innovations  for  protecting  multilevel  data  and  for  man¬ 
aging  security  policies  and  security  services  in  support  of 
critical  applications,  including: 

1.  A  distributed  high  assurance  architecture  for  control¬ 
ling  access  to  multiple  data  domains,  which  utilizes 
commercial  and  open  source  applications 

2.  A  high  assurance  distributed  trusted  path  mechanism 

3.  Access  to  existing  single-level  networks 

4.  A  QoSS  framework  providing  dynamic  (adaptive)  se¬ 
curity  services 

It  is  hoped  that  the  development  of  high-assurance,  highly 
usable  MLS  architectures  such  as  MYSEA  will  encourage 
the  adoption  of  MLS  computing  systems  by  the  entities  that 
stand  to  benefit  from  their  use. 

In  the  future,  we  intend  to  support  new  applications  in¬ 
cluding  voice  mail,  video  telephones,  and  webmail.  We  are 
also  exploring  multilevel  aware  collaboration  services,  and 
the  addition  of  QoSS  to  services  other  than  network  secu¬ 
rity.  Additional  future  work  includes  a  Network  File  System 
(NFS)  port  enhanced  with  ring-like  privileges  [68]  in  the  user 
domain,  to  help  constrain  the  behavior  of  applications,  and 
a  multilevel  aware  or  multilevel  DNS  service  [20]. 
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